Dave Dunn wrote:
> I have been using POV-Ray for almost nine years. I certainly know the
definition
> of x (or y or z for that matter). My remarks, which have universally been
taken
> as signs of ignorance, concerned the ergonomic fact that, for the special
case
> of scale, since POV *does* change the 0s to 1s (like it or not it does
this),
> that the warning for this case alone should not be given. The rationale
for this
> is that it is simply *as an end-user* easier to type scale x*.2 than
scale
> <.2,1,1>, when the internal parser is happily converting those offending
0s to
> 1s anyay. As a prograamer you may be horrified that I want the program to
make
> it easier for me to do something, but as a user, I want it as efficient as
I can
> get it.

You have to live with the fact that many users want POV to tell them if
something is going wrong in this direction (when designing transformation
macros for example). I know that you know what x, y and z mean, I just
wanted to focus on the fact that they work this way everywhere, and it would
be quite confusing if they had to work differently in different cases. As
Warp pointed out, the fact that those shortcuts work fine with some
transformations does not mean that they have to work fine everywhere.
Suppose you have a macro that (through a matrix) scale an object something
like <0.00000000000001,2.5,0.000000000000000001>. Suppose now that those
tiny numbers (due to inside approximation) are turned to 0. POV-Ray will
turn them to 1 and will warn you, so that you can undertand what's going on
and adapt your macro to those inside limits.
I understand what you mean, but I think that the most important thing for
the user it consistency. If we start to put here and there exceptions to the
rules, things won't be easier, but harder.

--
Jonathan.

Post a reply to this message